Business Rules Security: Check-in / Check-out

Overview

To avoid users overwriting each other's changes in Business Rules when working collaboratively, Bizagi provides a Check-in / Check-out functionality.

As soon as an Expression (scripting or Boolean) is opened to perform changes, it is automatically locked for other users.

Thus, the first user to open an Expression is able to change it. If someone else opens the same Expression while it is checked out, then a message will display informing who has it locked, and it will display as read-only, as shown below.

When in read-only mode, team members will be able to see the rule, but they won't be able to perform any changes since all the controls will be disabled and access to the expressions editor will not be enabled.

Check-in or Enabling for Edition

If the user that has the Expression locked closes it, it is automatically checked-in.

When an Expression has been checked in, it will be available for the rest of the users to edit. There is no option to manually check in an expression—closing it is the only way to make it available again.

Force Check-in

As a last resort option, in case there is an urgent need to modify an Expression that a user has checked out, the Force check-in feature is available.

The check-in / check-out functionality of Expressions is very important to prevent users from overwriting each other's work and to allow them to collaborate on a project efficiently. Nonetheless, there are situations where an Expression could be checked out for an extended period, preventing team members from making changes.

For example, a user checked out an Expression and locked their workstation before going on vacation. In this case, the rest of the team will not be able to make changes to that Expression until the user returns and checks it in. This is why the Force check-in feature was introduced.

This feature allows team members to force the check-in of an Expression locked by another user and check out the Expression in their own session. All unsaved changes will be lost.

The user who previously had the Expression locked will not enter read-only mode. However, if they try to perform any changes, a message will be displayed informing them that another team member has checked out the Expression and that it is not possible to perform changes at that time.

Example

Carolina Middleton and Jonathan Edelstein are working together on a collaborative project. Carolina accessed a rule, so it is blocked for Jonathan to edit it.

Jonathan noticed that Carolina has not checked in the rule for a long period of time. He contacted her to check on the situation. Carolina informed him that she is sick and will not return to work for a week. She gave him permission to force the check-in of the rule so he could continue working.

To force the check-in of the rule in his session, Jonathan clicks Carolina's name on the message displayed on the screen. Consequently, the following warning appears:

Since the users have already agreed on Jonathan forcing the check-in of the rule, he proceeds with the process.

Once he clicks Unlock expression, all unsaved changes made by Carolina will be lost, and Jonathan's application will exit read-only mode, allowing him to edit the rule. He must confirm again before proceeding.

After confirming, the rule is now checked out by Jonathan, meaning it will be blocked for Carolina or any other user to edit.

After clicking OK, Jonathan will have the rule unlocked and available for editing.

A week later, Carolina returns to work and immediately tries to perform changes to the rule. However, the rule is now locked by Jonathan. Even though she does not enter read-only mode, she is unable to perform changes, and Bizagi notifies her accordingly, as shown below.

This way, both Carolina and Jonathan can rest assured that working collaboratively in Bizagi will prevent overwriting risks, as the check-in / check-out functionality ensures that only one user can modify a rule at a time.